Tying to keep it simple, I was thinking of one ServletToolboxManager per toolbox.xml
this solves the runtimeSingleton mode problem as long as the multiple toolboxes case. thus I would propose a method like : static ServletToolboxManager.getManager( ServletContext context, String toolboxFile ) and internally, the ServletToolboxManager would maintain a hashtable from the toolbox.xml real path to its specific instances (this appears quite reasonable to have one manager per toolbox, no ?) About the pluggable behaviour : very easy to do from a "manager" init property that contains a class name, but then the proposed getManager method has to appear in the ToolboxManager interface. By the way, shouldn't the VVS properties be prefixed by "org.apache.velocity.tools" ? CloD ----- Original Message ----- From: "Nathan Bubna" <[EMAIL PROTECTED]> To: "Velocity Developers List" <[EMAIL PROTECTED]>; "Claude Brisson" <[EMAIL PROTECTED]> Sent: vendredi 10 janvier 2003 00:55 Subject: Re: [VELTOOLS] Why isn't ServletToolboxManager a singleton class ? > Claude said: > > Tim said: > > > Could that feature ever make a $LicenseToKill() tool available in places > > > that you wouldn't want it? > > > > If you have only one VVS it is already the case. > > > > If you have several VVS, then they can use different toolbox.xml, or the > same, as before. > > > > The point here is just to avoid re-initializing application/session scope > tools for each servlet (and that is a little more complex > > than I thought, since one has to avoid collisions between tools if > servlets use different toolbox.xml files, or also collisions > > between different webapps in runtimeSingleton mode... but nothing too hard > I guess). > > thinking about this aloud a bit more... > > i'm concerned at the idea of a singleton toolbox manager managing multiple > toolboxes. i'm not saying it couldn't or shouldn't be done (at least, i > don't think i'm saying that yet :), but this would involve a significant > shift in the duties of a ToolboxManager. as i see it, a single > ToolboxManager manages a single toolbox, not several. > > so, to make a ToolboxManager manage multiple toolboxes (i.e. different > toolbox.xml files for different servlets) worries me. primarily, i wonder > how the toolbox manager would tell which "box of tools" to initialize and > return when getToolboxContext() is called. and even should that question be > well answered, i suspect the resulting toolbox manager would have then > reached a level of complexity that most developers will never want or need. > > however, i think this is further motive for making the servlet toolbox > manager in VVS pluggable. then those few who need such complex tool > management can design a toolbox manager to fit their needs. > > i'm thinking it might be best to add a SingletonServletToolboxManager to > accompany Claude's initparam.patch (which, btw, looks good to me) for those > who wish to define one toolbox for all servlets in a webapp (still gotta > watch out for multiple webapps using the singleton) and leave the existing > ServletToolboxManager as default for those who are operating with one > toolbox.xml per VVS (i suspect the majority only use one VVS instance). > > thoughts anyone? > > Nathan Bubna > [EMAIL PROTECTED] > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
