Geir said:
> But my impression is that this is getting a bit over-designed : I am going
> to read the whole thread tomorrow - but has everyone stood back and asked
> the question (or answered it) :
>
>    Is there anything we can remove?

yup, plenty if you ask me.

> I like very much the idea of placing few if any requirements on the
tools -
> that the toolbox descriptor should suffice -> I would want to be able to
> specify  java.lang.String as a tool and control where and how it was
used...

i agree.  i think my proposal (already implemented and submitted) for
putting scope-placement wholly to the config file and having two completely
optional interfaces--one for application tools and one for request/session
tools--should suffice.
if that's still too much stuff for you, i personally don't ever plan on
using the application tool interface i proposed (ServletContextTool), i only
think it is something that someone may want.  perhaps we should stick with
just the one interface i proposed for request/session tools
(ViewContextTool) and add the other later if someone actually wants it.

the issues of logging and pooling for tools are of secondary importance to
me.

> And I am afraid that outside of the Struts integration part, it's getting
> framework-ish...

heh.  that may be...  perhaps we should leave any special logging or pooling
for tools out.  after all, tools that implement either of my proposed
interfaces have access to the servlet context and can just log directly thru
that if need be.  other than that, logging can easily be left for developers
to implement on their own. also, i suppose we should think carefully before
implementing anything that will add new dependencies (such as pooling).

> However, these are just random thoughts at the end of a long day towards
the
> end of a long week at the beginning of what will be a long month - so I
may
> be totally off base....

no, i don't think you're off base at all.  simple and clean sounds good to
me.

Nathan Bubna
[EMAIL PROTECTED]


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

Reply via email to