[VELTOOLS] Why isn't ServletToolboxManager a singleton class ?

[Claude Brisson <cl...@savoirweb.com>]

If using several VelocityViewServlet servlets (for instance one that requires authentification, one that doesn't), tools are initialized for each servlet, although application/session scoped tools should be shared.

To allow several VVS to share their ToolboxManager, we would need the ServletToolboxManager class to be a singleton.

If veltools developers agree, I submit such a patch.

Thanx,

CloD

Re: [VELTOOLS] Why isn't ServletToolboxManager a singleton class ?

[Nathan Bubna <na...@esha.com>]

Nathan said:
> Gabe said:
> > Claude Brisson wrote:
> >
> > > If using several VelocityViewServlet servlets (for instance one that
> requires authentification, one that doesn't), tools are initialized for
each
> servlet, although application/session scoped tools should be shared.
> > >
> > > To allow several VVS to share their ToolboxManager, we would need the
> ServletToolboxManager class to be a singleton.
> > >
> > > If veltools developers agree, I submit such a patch.
> >
> >
> > Yes, that would be nice. Does anyone see drawbacks to sharing tools
> between
> > VV Servlet? I don't.
>
> hmm.  no, i can't think of any drawbacks offhand.

one thing worth mentioning here...

i've suggested before that we make the toolbox manager used by the
VelocityViewServlet pluggable.  this would make it easy for developers to
plug custom toolbox managers into the VVS.  in conjunction with this, the
Velocity-Tools project could also then include different toolbox managers
(if so desired) as options for developers.   that said, if we could
establish a generic interface for servlet toolbox managers, we might then
include both a manager that fits Claude's needs as well as a simpler one for
those of us who use only one instance of the VVS.  i'd also like to look
into setting a toolbox manager that supported pooling using commons-pool.

thoughts?

Nathan Bubna
nathan@esha.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [VELTOOLS] Why isn't ServletToolboxManager a singleton class ?

[Nathan Bubna <na...@esha.com>]

Gabe said:
> Claude Brisson wrote:
>
> > If using several VelocityViewServlet servlets (for instance one that
requires authentification, one that doesn't), tools are initialized for each
servlet, although application/session scoped tools should be shared.
> >
> > To allow several VVS to share their ToolboxManager, we would need the
ServletToolboxManager class to be a singleton.
> >
> > If veltools developers agree, I submit such a patch.
>
>
> Yes, that would be nice. Does anyone see drawbacks to sharing tools
between
> VV Servlet? I don't.

hmm.  no, i can't think of any drawbacks offhand.

Nathan Bubna
nathan@esha.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [VELTOOLS] Why isn't ServletToolboxManager a singleton class ?

[Nathan Bubna <na...@esha.com>]

Claude said:
> > > 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 ?)
> >
> > yeah, this is pretty good.  how/where are you planning to do the loading
of
> > the toolbox.xml file?
>
> the getManager can take care of it and call the load(InputStream) method
if a new instance has to be built

+1

> > the ToolboxManager was not meant to be tied to the servlet API.
>
> Ah, right !
>
> > just require that
> > anyone plugging their own manager in make it extend
ServletToolboxManager.
> > (personally, i prefer the latter.)
>
> me too, that's the good solution
>
> > > By the way, shouldn't the VVS properties be prefixed by
> > "org.apache.velocity.tools" ?
> >
> > eh, that doesn't really follow the pattern of most velocity.props keys.
it
>
> of the ones that are inside the velocity.properties, that's true...
> but not of the only one which is in the web.xml :
> org.apache.velocity.properties = '/WEB-INF/velocity.properties'

ah.  i misunderstood.  i thought you were talking about the key for
specifying the ServletToolboxManager to be used. :)
so, yeah, i think you're right.  it would be better if the toolbox
<init-param> key in were "org.apache.velocity.tools.toolbox"

> So ? One prefix pattern for init-params and another for props files ? ;-)

yeah.  :)  that's fine, they're two quite separate things.

> > would be more inline to prefix VVS properties with something like
> > "tools.view.servlet".  so for the manager, i think
> > "tools.view.servlet.toolbox.manager.class"  would be a good key.
>
> As you wish, but we are speaking of a servlet init/context param, aren't
we ?
> Just as the "toolbox" param, which is not currently prefixed...

as i wish?  :)  sheesh.  i ain't even a committer here.  the final word on
these things belongs to Geir, Gabe, & company.  we'll need them to commit
these changes anyhow.  (and even if i were one, i'd still want to know if
you had another idea).

Nathan Bubna
nathan@esha.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [VELTOOLS] Why isn't ServletToolboxManager a singleton class ?

[Claude Brisson <cl...@savoirweb.com>]

> > 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 ?)
> 
> yeah, this is pretty good.  how/where are you planning to do the loading of
> the toolbox.xml file?

the getManager can take care of it and call the load(InputStream) method if a new instance has to be built

> the ToolboxManager was not meant to be tied to the servlet API.

Ah, right !

> just require that
> anyone plugging their own manager in make it extend ServletToolboxManager.
> (personally, i prefer the latter.)

me too, that's the good solution

> > By the way, shouldn't the VVS properties be prefixed by
> "org.apache.velocity.tools" ?
> 
> eh, that doesn't really follow the pattern of most velocity.props keys.  it

of the ones that are inside the velocity.properties, that's true...
but not of the only one which is in the web.xml : 
org.apache.velocity.properties = '/WEB-INF/velocity.properties'

So ? One prefix pattern for init-params and another for props files ? ;-)

> would be more inline to prefix VVS properties with something like
> "tools.view.servlet".  so for the manager, i think
> "tools.view.servlet.toolbox.manager.class"  would be a good key.

As you wish, but we are speaking of a servlet init/context param, aren't we ?
Just as the "toolbox" param, which is not currently prefixed...

CloD

----- Original Message ----- 
From: "Nathan Bubna" <na...@esha.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>; "Claude Brisson" <cl...@savoirweb.com>
Sent: vendredi 10 janvier 2003 20:41
Subject: Re: [VELTOOLS] Why isn't ServletToolboxManager a singleton class ?


> Claude said:
> > 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 ?)
> 
> yeah, this is pretty good.  how/where are you planning to do the loading of
> the toolbox.xml file?
> 
> > 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.
> 
> i agree, it shouldn't be difficult to do, but i'm against adding this
> getManager(ServletContext, String) method to the ToolboxManager interface.
> the ToolboxManager was not meant to be tied to the servlet API.  the current
> design was the result of a number of long discussions concerning the
> possibility/hope that some or all of this tool management library could at
> some point be used with non-servlet technologies (just as velocity proper
> is).  specifically, there was (much) discussion about similarly supporting
> tools/toolbox.xml for DVSL.
> 
> that said, we should be *very slow* to tie things firmly to a servlet
> environment if we wish to maintain that direction at all.  i think it would
> be preferable here to either have a ServletToolboxManager interface (with
> appropriate default implementation) or, more simply, just require that
> anyone plugging their own manager in make it extend ServletToolboxManager.
> (personally, i prefer the latter.)
> 
> > By the way, shouldn't the VVS properties be prefixed by
> "org.apache.velocity.tools" ?
> 
> eh, that doesn't really follow the pattern of most velocity.props keys.  it
> would be more inline to prefix VVS properties with something like
> "tools.view.servlet".  so for the manager, i think
> "tools.view.servlet.toolbox.manager.class"  would be a good key.
> 
> Nathan Bubna
> nathan@esha.com
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [VELTOOLS] Why isn't ServletToolboxManager a singleton class ?

[Nathan Bubna <na...@esha.com>]

Claude said:
> 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 ?)

yeah, this is pretty good.  how/where are you planning to do the loading of
the toolbox.xml file?

> 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.

i agree, it shouldn't be difficult to do, but i'm against adding this
getManager(ServletContext, String) method to the ToolboxManager interface.
the ToolboxManager was not meant to be tied to the servlet API.  the current
design was the result of a number of long discussions concerning the
possibility/hope that some or all of this tool management library could at
some point be used with non-servlet technologies (just as velocity proper
is).  specifically, there was (much) discussion about similarly supporting
tools/toolbox.xml for DVSL.

that said, we should be *very slow* to tie things firmly to a servlet
environment if we wish to maintain that direction at all.  i think it would
be preferable here to either have a ServletToolboxManager interface (with
appropriate default implementation) or, more simply, just require that
anyone plugging their own manager in make it extend ServletToolboxManager.
(personally, i prefer the latter.)

> By the way, shouldn't the VVS properties be prefixed by
"org.apache.velocity.tools" ?

eh, that doesn't really follow the pattern of most velocity.props keys.  it
would be more inline to prefix VVS properties with something like
"tools.view.servlet".  so for the manager, i think
"tools.view.servlet.toolbox.manager.class"  would be a good key.

Nathan Bubna
nathan@esha.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [VELTOOLS] Why isn't ServletToolboxManager a singleton class ?

[Claude Brisson <cl...@savoirweb.com>]

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" <na...@esha.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>; "Claude Brisson" <cl...@savoirweb.com>
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
> nathan@esha.com
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [VELTOOLS] Why isn't ServletToolboxManager a singleton class ?

[Nathan Bubna <na...@esha.com>]

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
nathan@esha.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [VELTOOLS] Why isn't ServletToolboxManager a singleton class ?

[Claude Brisson <cl...@savoirweb.com>]

> 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).

CloD

----- Original Message -----
From: "Tim Colson" <tc...@cisco.com>
To: "'Velocity Developers List'" <ve...@jakarta.apache.org>
Sent: jeudi 9 janvier 2003 18:20
Subject: RE: [VELTOOLS] Why isn't ServletToolboxManager a singleton class ?


> > Yes, that would be nice. Does anyone see drawbacks
> > to sharing tools between VV Servlet? I don't.
> Could that feature ever make a $LicenseToKill() tool available in places
> that you wouldn't want it?
>
> Tim
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [VELTOOLS] Why isn't ServletToolboxManager a singleton class ?

[Tim Colson <tc...@cisco.com>]

> Yes, that would be nice. Does anyone see drawbacks 
> to sharing tools between VV Servlet? I don't.
Could that feature ever make a $LicenseToKill() tool available in places
that you wouldn't want it?

Tim


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [VELTOOLS] Why isn't ServletToolboxManager a singleton class ?

[Gabriel Sidler <si...@teamup.com>]

Claude Brisson wrote:

> If using several VelocityViewServlet servlets (for instance one that requires authentification, one that doesn't), tools are initialized for each servlet, although application/session scoped tools should be shared.
> 
> To allow several VVS to share their ToolboxManager, we would need the ServletToolboxManager class to be a singleton.
> 
> If veltools developers agree, I submit such a patch.


Yes, that would be nice. Does anyone see drawbacks to sharing tools between
VV Servlet? I don't.

Gabe




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


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>