velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriel Sidler <>
Subject Re: [Veltools] ToolboxManager (round 4 :-)
Date Fri, 03 May 2002 15:49:06 GMT
Ok, I got your points. I do not agree with all your arguments but these
point of disagreement are mostly related to possible future uses of the
software in other environments. I think that the current proposal supports
all the key features that we need to move on. Feedback from users and real
applications will tell us in the future if all the design decisions were

The one thing that I really would like to get fixed is the synchronization
of the instantiation of the session tools (see my points below).

I propose that you send me all the modifed files and I will
then check them in. Please make sure that the JavaDoc is reflecting the
latest design.

I have added some replys to your comments below.


Nathan Bubna wrote:

> Gabe said:

>>- In our past discussion Dan argued for a destroy() method
>>as part of the ContextTool interface. This would be the place to do
>>clean-up work or release resources. Your current proposal doesn't
>>address this. What's your thinking on that.
> actually, i did address it, but here it is again:
> Nathan said:
>>I can also envision someone creating a Poolable interface that offers a
>>destroy()/reset() method, and implementing a PoolableToolInfo class that
>>pools instances of Poolable tools in order to more efficiently implement
>>getInstance().  I'm not convinced that these belong in this project

I am not talking about the pooling of tools. There are two different issues
here. One issue is the need to release resources after the tool has been used.
A proposed solution was to have a destroy() method. Dan reported a need for
that (it was part of the original design but removed later). The other issue
is the pooling of tools for efficiency. We agree that this is not high priority
right now.


>>- ServletToolboxManager.getToolboxContext(): The instantiation of
>>   session tools should be synchronized, otherwise it might happen that
>>   the session-scoped tools are instantiated multiple times for the same
>>   session.
> this too has been discussed at length.  i think it's an incredibly paranoid
> thing to do.  if done correctly, it wouldn't be too much of a performance
> hit, but IMO, if the current design is problematic for a tool designer, it
> is the fault of their tool design, not the fault of the toolbox manager.
> anyway, you seem stuck on the idea, and i can't stop you from doing it.  so
> do what you will, i'm tired of arguing about it.

You are mixing two things: You are talking about the thread safety of
tools. I am talking about the thread-safety of the toolbox manager.
I don't understand why we need so much discussion about thread-safety.
This is not an esoteric, magical concept but rather a basic concept of
software engineering.
A piece of software that is used concurrently from multiple threads must
be thread-safe. Anything else is a bug. This is pretty black and white
in my view. I don't think this has anything to do with being paranoid.

I worked on a large collaborative web appliation for a call center
environment; kind of a chat tool for customer support. We've had our share
of threading problems. I can assure you that these problems are real and
do happen. There is not much that is worse to debug. It is really worth
to pay attention to this.

>>- I am quite uncomfortable with the proposed init method of ContextTool.
>>     public void init(Object initData);
>>   This is virtually moving us back to C-times where we worked with pointers
>>   and suffered from all kind of related problems. The interface is basically
>>   specified through the documentation. Yes, this approach
>>   keeps the interface between tools and the toolbox manager simple. But,
>>   the price is a problematic, underspecified, error-prone interface.
> That's too high a price.
> Really?  I'll be sure to pass that on to Turbine-land where this has worked
> great for their PullService for quite some time now.  Someone should warn
> them of their impending doom!  :-)  ok, maybe that's a little dramatic...

Well, I don't think this pull tool interface it their masterpiece of software
engineering. It's a working compromise.

> And where do you get this "problematic, underspecified, error-prone" stuff?
> I see no problems (remember, i've already implemented and tested this code
> and it worked great!). 

In your design, the interface between toolbox manager and tools is partially
defined in the documentation. This makes it impossible for a compiler or
the toolbox manager to detect a mismatch of classes. I tought we left that
behind with C...

In any case, for the current environment the current proposal is a working
proposal. That's why I propose that we incorporate your current proposal
and move on.


>>Nathan wrote:
>> > (Gabe, if you would really prefer to call this "ViewTool",  I can live
>> with it.  But i still think ContextTool will be more meaningful to users.)
>>I really would prefer ViewTool. From talking to people, my experience
>>is that ViewTool is more intuitive than ContextTool.
> your experience perhaps, but not mine.  i've been lurking on the velocity
> lists for well over a year and never heard the term 'view tool' until you
> committed that change to the veltools project.

So you can't live with it? :-)

> >>Furthermore, there is nothing about these tools that is specific to
>>the context.
> ?  so it doesn't mean anything to you that the whole purpose of these tools
> is to be placed in the velocity context?

I claim that the purpose of these tools is not to be placed in the
Velocity context but to provide some utility to the view layer,
whatever this view layer is. :-)

I personally use some of my view tools in JSP and Velocity. I am
sure many Struts users would want to do the same. The name context tool
doesn't really have a meaning outside of Velocity. But, many view tools
have very much a purpose outside the Velocity environment. So, we can
use our own terminology or use something that has a meaning in other
environments as well. Another term I occasionally read on the Struts
list is "view helper"

I think enough has been said. Let's get this code into the repository.
I want to get the Struts stuff out to Struts users so that we can
gather some real feedback.


Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message