Bill Burton wrote:

> Gabriel Sidler wrote:
>>If 'scope' is not the right term here, let me what would be better.
>>
> 
> The concept of "scope" and "contextname" mentioned earlier are really just
> about the same thing.  


Sorry, I don't see that. Wasn't "contextname" just the name of the
toolbox in the context? Scope, on the other hand, says something about
the lifecycle of a tool (at least in my understanding :-)) Our Velstruts
implementation maps all tools flat into the same namespace. I get the
impression that your understanding of scope is related to dividing the
context namespace into subspaces.

I'm still not sure that we all mean the same when we say 'scope' :-(
Maybe 'scope' is really the wrong term for the concept that I thinking
of. Maybe 'lifecycle' would be more accuratly expressing the concept.

Here's my understanding:
'livecycle' ('scope') is an attribute of a tool that specifies the
life duration of a tool. Two typical 'livecycles' are
a) the duration of processing one template
b) the entire runtime of the program
In the first case, tools are instantiated to process one template and
then discarded. In the second case tools are instantiated once and
kept for the entire runtime of the program. This is not realated at
all to the addressing of tools in the context.


> However, ToolboxManager should not use global scope by default when
> loading a tool (in the servlet environment) because this implies the tool
> is thread safe.  The default should be request.  


That is a good point. But, it's really a performance trade-off. Assigning
a 'livecycle' of 'request' by default would mean that tools have to be
re-instantiated for every template being processed. That could potentially
add a lot of burden to every request. Is it unreasonable to require that
context tools are thread safe?

Gabe


> Also, instead of calling it "global", a term which I don't ever recall
> seeing associated with the ServletContext, maybe the term "application"
> would be better.  
> 
> -Bill

--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to